Skip to content

Harden dependency update handling#571

Open
bgentry wants to merge 1 commit into
masterfrom
bg/dep-updates-3-day-delay
Open

Harden dependency update handling#571
bgentry wants to merge 1 commit into
masterfrom
bg/dep-updates-3-day-delay

Conversation

@bgentry
Copy link
Copy Markdown
Contributor

@bgentry bgentry commented May 13, 2026

Dependency update safety is mostly handled by Dependabot timing and npm install behavior, so this adds project npm settings that reject packages published less than three days ago, block git dependency refs, and require the expected Node/npm engines.

CI, release packaging, and Docker builds now use Node 24.14.1 with npm ci so installs follow the committed lockfile and project npm policy. Dependabot also covers Docker Compose and GitHub Actions with cooldowns, while Docker and Compose image refs are pinned to patch tags plus digests so image changes happen through reviewable dependency PRs instead of silent tag drift.

Add npm configuration that enforces a minimum release age, blocks git
package refs, and requires the expected Node/npm engine versions. CI,
release packaging, and Docker builds now use Node 24.14.1 with `npm ci`
so installs follow the committed lockfile and project npm policy.

Extend Dependabot coverage and cooldowns for Docker, Docker Compose, and
GitHub Actions so regular dependency update PRs are delayed and reviewed
through the usual workflow. Pin Docker and compose image refs to explicit
patch tags and digests, including Postgres 18 for local development, so
image changes happen through visible dependency updates instead of silent
tag drift.
@bgentry bgentry force-pushed the bg/dep-updates-3-day-delay branch from 1c19811 to cdb3209 Compare May 13, 2026 21:32
Comment thread Dockerfile
# syntax=docker/dockerfile:1

FROM node:22-alpine AS build-ui
FROM node:24.14.1-alpine@sha256:8510330d3eb72c804231a834b1a8ebb55cb3796c3e4431297a24d246b8add4d5 AS build-ui
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's some ergonomic downside to attaching these big SHAs to everything — it just makes updating these things harder.

I'm not sure there's that big security benefit either. You're making the build more reproducible I suppose, but there's no way for a human to distinguish the safety of one of these giant SHA hashes from another giant SHA hash. i.e. If you dropped in a compromised hash here on a future upgrade, there's no way I'd be able to recognize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants